Users lose files or the data within files in many ways. One common way is by accidental deletion of a file. Contemporary operating systems offer “recycle bin” functionality or the like allows some files to be recovered, however not all mechanisms that delete files do so by moving them to the recycle bin. Further, even when deleting files with recycle bin-enabled mechanisms, those mechanisms allow for files to be permanently deleted, without being put in the recycle bin, e.g., by using Shift-Delete instead of the Delete key.
Another common way that users lose information is by accidentally overwriting a file. For example, users often create a new file by opening an existing file, making modifications to it, and then saving the file with a new name. However, if the user forgets to save the file using a new name, the original file data is overwritten. As can be readily appreciated, the presence of a recycle bin does nothing to protect against this type of data loss.
Yet another common way that users lose information is not by mistake, but by sharing files with others who make changes. For example, during the normal course of working on a document, multiple users may make changes to that document at various times. At a later time, a user may want to have a copy of what the document contained before one or more colleagues altered it.
Although various backup mechanisms exist, they do not solve these problems in many cases. For example, if the backup was performed too long ago, the file may not exist. Additionally, even if a backup copy exists, it may be difficult or not worthwhile to recover. For example, corporate policy may prevent the information services department from performing a single file restore, or there may be a large cost charged to recover a document, which the user's department will not accept. Further, a user may decide (e.g., out of embarrassment or apprehension) that it is better to work overtime to recreate a document as best as possible than it is to have the loss of the document publicized.
Similarly, although versioning systems exist that keep versions of volumes, such versioning systems are not easy to use. For example, such systems simply maintain an image of a network shared folder subtree and the files therein at a given time, with subtree images kept for various times. To find a file version, a user needs to navigate through a selected subtree. Then, if the file existed at the time the subtree image was preserved, but it is not the desired version, or the user is uncertain which exact version is best, the user may have to navigate back up to folder that keeps the subtrees and then back down through one of the other available subtree images, repeating for some or all of the subtrees until the desired version is found. In fact, depending on how often the images are preserved, many of the file versions may be the same as other versions, yet until the user navigates to each one, the user may not know that a particular file version need not be checked. Moreover, such navigation gets even more complicated with distributed file systems, wherein the subtrees may be distributed across multiple file servers. For example, navigation may not be as simple as going up a chain of parent folders or down to child folders, since the server identity may change as subtrees are changed.
In sum, files and/or their information may be lost in many ways, yet in many cases, users do not have the ability to easily correct such problems, and instead have to resort to costly or difficult alternatives.